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Abstract 


The invention of a large-scale quantum computer would pose a serious challenge for the 
cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax 
(CMS) supports key transport and key agreement algorithms that could be broken by the 
invention of such a quantum computer. By storing communications that are protected with the 
CMS today, someone could decrypt them in the future when a large-scale quantum computer 
becomes available. Once quantum-secure key management algorithms are available, the CMS 
will be extended to support the new algorithms if the existing syntax does not accommodate 
them. This document describes a mechanism to protect today's communication from the future 
invention of a large-scale quantum computer by mixing the output of key transport and key 
agreement algorithms with a pre-shared key. 
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1. Introduction 


The invention of a large-scale quantum computer would pose a serious challenge for the 
cryptographic algorithms that are widely deployed today [S1994]. It is an open question whether 
or not it is feasible to build a large-scale quantum computer and, if so, when that might happen 
[NAS2019]. However, if such a quantum computer is invented, many of the cryptographic 
algorithms and the security protocols that use them would become vulnerable. 


The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports key transport and key 
agreement algorithms that could be broken by the invention of a large-scale quantum computer 
[C2PQ]. These algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and Elliptic Curve 
Diffie-Hellman (ECDH) [RFC5753]. As a result, an adversary that stores CMS-protected 
communications today could decrypt those communications in the future when a large-scale 
quantum computer becomes available. 


Once quantum-secure key management algorithms are available, the CMS will be extended to 
support them if the existing syntax does not already accommodate the new algorithms. 


In the near term, this document describes a mechanism to protect today's communication from 
the future invention of a large-scale quantum computer by mixing the output of existing key 
transport and key agreement algorithms with a pre-shared key (PSK). Secure communication can 
be achieved today by mixing a strong PSK with the output of an existing key transport algorithm, 
like RSA [RFC8017], or an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or 
Elliptic Curve Diffie-Hellman (ECDH) [RFC5753]. A security solution that is believed to be 
quantum resistant can be achieved by using a PSK with sufficient entropy along with a quantum- 
resistant key derivation function (KDF), like an HMAC-based key derivation function (HKDF) 
[RFC5869], and a quantum-resistant encryption algorithm, like 256-bit AES [AES]. In this way, 
today's CMS-protected communication can be resistant to an attacker with a large-scale quantum 
computer. 


In addition, there may be other reasons for including a strong PSK besides protection against the 
future invention of a large-scale quantum computer. For example, there is always the possibility 
of a cryptoanalytic breakthrough on one or more classic public key algorithms, and there are 
longstanding concerns about undisclosed trapdoors in Diffie-Hellman parameters [FGHT2016]. 
Inclusion of a strong PSK as part of the overall key management offers additional protection 
against these concerns. 


Note that the CMS also supports key management techniques based on symmetric key-encryption 
keys and passwords, but they are not discussed in this document because they are already 
quantum resistant. The symmetric key-encryption key technique is quantum resistant when used 
with an adequate key size. The password technique is quantum resistant when used with a 
quantum-resistant key derivation function and a sufficiently large password. 
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1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


1.2. ASN.1 


CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the 
Distinguished Encoding Rules (DER) [X690]. 


1.3. Version Numbers 


The major data structures include a version number as the first item in the data structure. The 
version number is intended to avoid ASN.1 decode errors. Some implementations do not check 
the version number prior to attempting a decode; then, if a decode error occurs, the version 
number is checked as part of the error-handling routine. This is a reasonable approach; it places 
error processing outside of the fast path. This approach is also forgiving when an incorrect 
version number is used by the sender. 


Whenever the structure is updated, a higher version number will be assigned. However, to 
ensure maximum interoperability, the higher version number is only used when the new syntax 
feature is employed. That is, the lowest version number that supports the generated syntax is 
used. 


2. Overview 


The CMS enveloped-data content type [RFC5652] and the CMS authenticated-enveloped-data 
content type [RFC5083] support both key transport and key agreement public key algorithms to 
establish the key used to encrypt the content. No restrictions are imposed on the key transport or 
key agreement public key algorithms, which means that any key transport or key agreement 
algorithm can be used, including algorithms that are specified in the future. In both cases, the 
sender randomly generates the content-encryption key, and then all recipients obtain that key. 
All recipients use the sender-generated symmetric content-encryption key for decryption. 


This specification defines two quantum-resistant ways to establish a symmetric key-encryption 
key, which is used to encrypt the sender-generated content-encryption key. In both cases, the PSK 
is used as one of the inputs to a key-derivation function to create a quantum-resistant key- 
encryption key. The PSK MUST be distributed to the sender and all of the recipients by some out- 
of-band means that does not make it vulnerable to the future invention of a large-scale quantum 
computer, and an identifier MUST be assigned to the PSK. It is best if each PSK has a unique 
identifier; however, if a recipient has more than one PSK with the same identifier, the recipient 
can try each of them in turn. A PSK is expected to be used with many messages, with a lifetime of 
weeks or months. 
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The content-encryption key or content-authenticated-encryption key is quantum resistant, and 
the sender establishes it using these steps: 


When using a key transport algorithm: 


1. The content-encryption key or the content-authenticated-encryption key, called "CEK", is 
generated at random. 


2. The key-derivation key, called "KDK", is generated at random. 


3. For each recipient, the KDK is encrypted in the recipient's public key, then the KDF is used to 
mix the PSK and the KDK to produce the key-encryption key, called "KEK". 


4. The KEK is used to encrypt the CEK. 
When using a key agreement algorithm: 


1. The content-encryption key or the content-authenticated-encryption key, called "CEK", is 
generated at random. 


2. For each recipient, a pairwise key-encryption key, called "KEK1", is established using the 
recipient's public key and the sender's private key. Note that KEK1 will be used as a key- 
derivation key. 


3. For each recipient, the KDF is used to mix the PSK and the pairwise KEK1, and the result is 
called "KEK2". 


4. For each recipient, the pairwise KEK2 is used to encrypt the CEK. 


As specified in Section 6.2.5 of [RFC5652], recipient information for additional key management 
techniques is represented in the OtherRecipientInfo type. Two key management techniques are 
specified in this document, and they are each identified by a unique ASN.1 object identifier. 


The first key management technique, called "keyTransPSK" (see Section 3), uses a key transport 
algorithm to transfer the key-derivation key from the sender to the recipient, and then the key- 
derivation key is mixed with the PSK using a KDF. The output of the KDF is the key-encryption 
key, which is used for the encryption of the content-encryption key or content-authenticated- 
encryption key. 


The second key management technique, called "keyAgreePSK" (see Section 4), uses a key 
agreement algorithm to establish a pairwise key-encryption key. This pairwise key-encryption 
key is then mixed with the PSK using a KDF to produce a second pairwise key-encryption key, 
which is then used to encrypt the content-encryption key or content-authenticated-encryption 
key. 


3. keyTransPSK 


Per-recipient information using keyTransPSK is represented in the KeyTransPSkRecipientInfo 
type, which is indicated by the id-ori-keyTransPSK object identifier. Each instance of 
KeyTransPSkRecipientInfo establishes the content-encryption key or content-authenticated- 
encryption key for one or more recipients that have access to the same PSK. 
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The id-ori-keyTransPSK object identifier is: 


id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } 


id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 
The KeyTransPSkKRecipientInfo type is: 


KeyTransPSkRecipientiInfo ::= SEQUENCE { 
version CMSVersion, -- always set to 0 
pskid PreSharedKeylIdentifier, 
kdfAlgorithm KeyDerivationAlgorithmIdenti fier, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
ktris KeyTransRecipientIinfos, 
encryptedKey EncryptedKey } 


PreSharedKeyIdentifier ::= OCTET STRING 


KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientiInfo 


The fields of the KeyTransPSKRecipientInfo type have the following meanings: 


e version is the syntax version number. The version MUST be 0. The CMSVersion type is 
described in Section 10.2.5 of [RFC5652]. 


e pskid is the identifier of the PSK used by the sender. The identifier is an OCTET STRING, and 
it need not be human readable. 


kdfAlgorithm identifies the key-derivation algorithm and any associated parameters used by 
the sender to mix the key-derivation key and the PSK to generate the key-encryption key. The 
KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652]. 


keyEncryptionAlgorithm identifies a key-encryption algorithm used to encrypt the content- 
encryption key. The KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 
[RFC5652]. 


ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport 
algorithm to establish the key-derivation key. That is, the encryptedKey field of 
KeyTransRecipientInfo contains the key-derivation key instead of the content-encryption key. 
KeyTransRecipientinfo is described in Section 6.2.1 of [RFC5652]. 


encryptedKey is the result of encrypting the content-encryption key or the content- 


authenticated-encryption key with the key-encryption key. EncryptedKey is an OCTET 
STRING. 
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4. keyAgreePSK 


Per-recipient information using keyAgreePSK is represented in the KeyAgreePSKRecipientInfo 
type, which is indicated by the id-ori-keyAgreePSK object identifier. Each instance of 
KeyAgreePSKRecipientInfo establishes the content-encryption key or content-authenticated- 
encryption key for one or more recipients that have access to the same PSK. 


The id-ori-keyAgreePSK object identifier is: 


id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 
The KeyAgreePSkKRecipientInfo type is: 
KeyAgreePSkRecipientInfo ::= SEQUENCE { 
version CMSVersion, -- always set to 0 


pskid PreSharedKeyIdentifier, 

originator [0] EXPLICIT OriginatorIdentifierOrKey, 

ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 
kdfAlgorithm KeyDerivationAlgorithmIdenti fier, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
recipientEncryptedKeys RecipientEncryptedKeys } 


The fields of the KeyAgreePSKRecipientInfo type have the following meanings: 


e version is the syntax version number. The version MUST be 0. The CMSVersion type is 
described in Section 10.2.5 of [RFC5652]. 


e pskid is the identifier of the PSK used by the sender. The identifier is an OCTET STRING, and 
it need not be human readable. 


originator is a CHOICE with three alternatives specifying the sender's key agreement public 
key. Implementations MUST support all three alternatives for specifying the sender's public 
key. The sender uses their own private key and the recipient's public key to generate a 
pairwise key-encryption key. A KDF is used to mix the PSK and the pairwise key-encryption 
key to produce a second key-encryption key. The OriginatorIdentifierOrKey type is described 
in Section 6.2.2 of [RFC5652]. 


ukm is optional. With some key agreement algorithms, the sender provides a User Keying 
Material (UKM) to ensure that a different key is generated each time the same two parties 
generate a pairwise key. Implementations MUST accept a KeyAgreePSKRecipientInfo 
SEQUENCE that includes a ukm field. Implementations that do not support key agreement 
algorithms that make use of UKMs MUST gracefully handle the presence of UKMs. The 
UserKeyingMaterial type is described in Section 10.2.6 of [RFC5652]. 


kdfAlgorithm identifies the key-derivation algorithm and any associated parameters used by 
the sender to mix the pairwise key-encryption key and the PSK to produce a second key- 
encryption key of the same length as the first one. The KeyDerivationAlgorithmIdentifier is 
described in Section 10.1.6 of [RFC5652]. 


keyEncryptionAlgorithm identifies a key-encryption algorithm used to encrypt the content- 
encryption key or the content-authenticated-encryption key. The 
KeyEncryptionAlgorithmIdentifier type is described in Section 10.1.3 of [RFC5652]. 
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5. 


recipientEncryptedKeys includes a recipient identifier and encrypted key for one or more 
recipients. The KeyAgreeRecipientIdentifier is a CHOICE with two alternatives specifying the 
recipient's certificate, and thereby the recipient's public key, that was used by the sender to 
generate a pairwise key-encryption key. The encryptedKey is the result of encrypting the 
content-encryption key or the content-authenticated-encryption key with the second 
pairwise key-encryption key. EncryptedKey is an OCTET STRING. The 
RecipientEncryptedKeys type is defined in Section 6.2.2 of [RFC5652]. 


Key Derivation 


Many KDFs internally employ a one-way hash function. When this is the case, the hash function 
that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] is 
one example of a KDF that makes use of a hash function. 


Other KDFs internally employ an encryption algorithm. When this is the case, the encryption that 
is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. For example, AES-128- 
CMAC can be used for randomness extraction in a KDF as described in [NIST2018]. 


A KDF has several input values. This section describes the conventions for using the KDF to 
compute the key-encryption key for KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. 
For simplicity, the terminology used in the HKDF specification [RFC5869] is used here. 


The KDF inputs are: 


IKM is the input keying material; it is the symmetric secret input to the KDF. For 
KeyTransPSkRecipientInfo, it is the key-derivation key. For KeyAgreePSKRecipientInfo, it is 
the pairwise key-encryption key produced by the key agreement algorithm. 


salt is an optional non-secret random value. Many KDFs do not require a salt, and the 
KeyDerivationAlgorithmIdentifier assignments for HKDF [RFC8619] do not offer a parameter 
for a salt. If a particular KDF requires a salt, then the salt value is provided as a parameter of 
the KeyDerivationAlgorithmIdentifier. 


Lis the length of output keying material in octets; the value depends on the key-encryption 
algorithm that will be used. The algorithm is identified by the 
KeyEncryptionAlgorithmIdentifier. In addition, the OBJECT IDENTIFIER portion of the 
KeyEncryptionAlgorithmIdentifier is included in the next input value, called "info". 


info is optional context and application specific information. The DER encoding of 
CMSORIforPSKOtherInfo is used as the info value, and the PSK is included in this structure. 
Note that EXPLICIT tagging is used in the ASN.1 module that defines this structure. For 
KeyTransPSkRecipientInfo, the ENUMERATED value of 5 is used. For 
KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is 
defined by the following ASN.1 structure: 


Housley Standards Track Page 9 


RFC 8696 Using PSK in the CMS December 2019 


CMSORIforPSKOtherInfo ::= SEQUENCE { 
psk OCTET STRING, 
keyMgmtALgType ENUMERATED { 
keyTrans (Gs 
keyAgree (10) }, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
pskLength INTEGER (1..MAX), 
kdkLength INTEGER (1..MAX) } 


The fields of type CMSORIforPSKOtherInfo have the following meanings: 


e psk is an OCTET STRING; it contains the PSK. 

e keyMgmtAlgType is either set to 5 or 10. For KeyTransPSKRecipientInfo, the ENUMERATED 
value of 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. 

e keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, which identifies the 
algorithm and provides algorithm parameters, if any. 

e pskLength is a positive integer; it contains the length of the PSK in octets. 

e kdkLength is a positive integer; it contains the length of the key-derivation key in octets. For 
KeyTransPSkRecipientInfo, the key-derivation key is generated by the sender. For 
KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise key-encryption key 
produced by the key agreement algorithm. 


The KDF output is: 


e OKM is the output keying material, which is exactly L octets. The OKM is the key-encryption 
key that is used to encrypt the content-encryption key or the content-authenticated- 
encryption key. 


An acceptable KDF MUST accept IKM, L, and info inputs; an acceptable KDF MAY also accept salt 
and other inputs. All of these inputs MUST influence the output of the KDF. If the KDF requires a 
salt or other inputs, then those inputs MUST be provided as parameters of the 
KeyDerivationAlgorithmIdentifier. 


6. ASN.1 Module 


This section contains the ASN.1 module for the two key management techniques defined in this 
document. This module imports types from other ASN.1 modules that are defined in [RFC5912] 


and [RFC6268]. 
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<CODE BEGINS> 


CMSORIforPSK-2019 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
smime(16) modules(@) id-mod-cms-ori-psk-2019(69) } 


DEFINITIONS EXPLICIT TAGS ::= 
BEGIN 


-- EXPORTS ALL 
IMPORTS 


Algorithmidentifier{}, KEY-DERIVATION 
FROM AlgorithmInformation-2009 -- [RFC5912] 
{ iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) id-mod(0) 
id-mod-algorithmIinformation-02(58) } 


OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 
KeyTransRecipientInfo, OriginatorIdentifierOrKey, 
UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 
KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdenti fier 
FROM CryptographicMessageSyntax-2010 -- [RFC6268] 
{ iso(1) member-body(2) us(840) rsadsi (113549) 
pkcs(1) pkcs-9(9) smime(16) modules(0) 
id-mod-cms-2009(58) } ; 


-- OtherRecipientInfo Types (ori-) 


SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 
ori-keyTransPSK | 
ori-keyAgreePSK, 


-- Key Transport with Pre-Shared Key 


ori-keyTransPSK OTHER-RECIPIENT ::= { 
KeyTransPSkKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } 
id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 
KeyTransPSkRecipientInfo ::= SEQUENCE { 
version CMSVersion, -- always set to 0 


pskid PreSharedKeyIdentifier, 

kdfAlgorithm KeyDerivationAlgorithmIdentifier, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
ktris KeyTransRecipientinfos, 

encryptedKey EncryptedKey } 


PreSharedKeyIdentifier ::= OCTET STRING 
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KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 


-- Key Agreement with Pre-Shared Key 


ori-keyAgreePSK OTHER-RECIPIENT ::= { 
KeyAgreePSkKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 
id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 
KeyAgreePSkRecipientInfo ::= SEQUENCE { 
version CMSVersion, -- always set to 0 


pskid PreSharedkeyIdentifier, 

originator [0] EXPLICIT OriginatorIdentifierOrKey, 

ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 
kdfAlgorithm KeyDerivationAlgorithmIdentifier, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
recipientEncryptedKeys RecipientEncryptedKeys } 


-- Structure to provide 'info' input to the KDF, 
-- including the Pre-Shared Key 


CMSORIforPSKOtherInfo ::= SEQUENCE { 
psk OCTET STRING; 
keyMgmtALgType ENUMERATED { 
keyTrans Ch 
keyAgree (10) F, 
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 
pskLength INTEGER (1..MAX), 
kdkLength INTEGER (1..MAX) } 
END 


<CODE ENDS> 


7. Security Considerations 


The security considerations related to the CMS enveloped-data content type in [RFC5652] and the 
security considerations related to the CMS authenticated-enveloped-data content type in 
[RFC5083] continue to apply. 


Implementations of the key derivation function must compute the entire result, which, in this 
specification, is a key-encryption key, before outputting any portion of the result. The resulting 
key-encryption key must be protected. Compromise of the key-encryption key may result in the 
disclosure of all content-encryption keys or content-authenticated-encryption keys that were 
protected with that keying material; this, in turn, may result in the disclosure of the content. Note 
that there are two key-encryption keys when a PSK with a key agreement algorithm is used, with 
similar consequences for the compromise of either one of these keys. 
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Implementations must protect the PSK, key transport private key, agreement private key, and 
key-derivation key. Compromise of the PSK will make the encrypted content vulnerable to the 
future invention of a large-scale quantum computer. Compromise of the PSK and either the key 
transport private key or the agreement private key may result in the disclosure of all contents 
protected with that combination of keying material. Compromise of the PSK and the key- 
derivation key may result in the disclosure of all contents protected with that combination of 
keying material. 


A large-scale quantum computer will essentially negate the security provided by the key 
transport algorithm or the key agreement algorithm, which means that the attacker with a large- 
scale quantum computer can discover the key-derivation key. In addition, a large-scale quantum 
computer effectively cuts the security provided by a symmetric key algorithm in half. Therefore, 
the PSK needs at least 256 bits of entropy to provide 128 bits of security. To match that same level 
of security, the key derivation function needs to be quantum resistant and produce a key- 
encryption key that is at least 256 bits in length. Similarly, the content-encryption key or content- 
authenticated-encryption key needs to be at least 256 bits in length. 


When using a PSK with a key transport or a key agreement algorithm, a key-encryption key is 
produced to encrypt the content-encryption key or content-authenticated-encryption key. If the 
key-encryption algorithm is different than the algorithm used to protect the content, then the 
effective security is determined by the weaker of the two algorithms. If, for example, content is 
encrypted with 256-bit AES and the key is wrapped with 128-bit AES, then, at most, 128 bits of 
protection are provided. Implementers must ensure that the key-encryption algorithm is as 
strong or stronger than the content-encryption algorithm or content-authenticated-encryption 
algorithm. 


The selection of the key-derivation function imposes an upper bound on the strength of the 
resulting key-encryption key. The strength of the selected key-derivation function should be at 
least as strong as the key-encryption algorithm that is selected. NIST SP 800-56C Revision 1 
[NIST2018] offers advice on the security strength of several popular key-derivation functions. 


Implementers should not mix quantum-resistant key management algorithms with their non- 
quantum-resistant counterparts. For example, the same content should not be protected with 
KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the same content should not be 
protected with KeyAgreeRecipientInfo and KeyAgreePSKRecipientInfo. Doing so would make the 
content vulnerable to the future invention of a large-scale quantum computer. 


Implementers should not send the same content in different messages, one using a quantum- 
resistant key management algorithm and the other using a non-quantum-resistant key 
management algorithm, even if the content-encryption key is generated independently. Doing so 
may allow an eavesdropper to correlate the messages, making the content vulnerable to the 
future invention of a large-scale quantum computer. 


This specification does not require that PSK be known only by the sender and recipients. The PSK 
may be known to a group. Since confidentiality depends on the key transport or key agreement 
algorithm, knowledge of the PSK by other parties does not inherently enable eavesdropping. 
However, group members can record the traffic of other members and then decrypt it if they 
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ever gain access to a large-scale quantum computer. Also, when many parties know the PSK, 
there are many opportunities for theft of the PSK by an attacker. Once an attacker has the PSK, 
they can decrypt stored traffic if they ever gain access to a large-scale quantum computer in the 
same manner as a legitimate group member. 


Sound cryptographic key hygiene is to use a key for one and only one purpose. Use of the 
recipient's public key for both the traditional CMS and the PSK-mixing variation specified in this 
document would be a violation of this principle; however, there is no known way for an attacker 
to take advantage of this situation. That said, an application should enforce separation whenever 
possible. For example, a purpose identifier for use in the X.509 extended key usage certificate 
extension [RFC5280] could be identified in the future to indicate that a public key should only be 
used in conjunction with or without a PSK. 


Implementations must randomly generate key-derivation keys as well as content-encryption keys 
or content-authenticated-encryption keys. Also, the generation of public/private key pairs for the 
key transport and key agreement algorithms rely on random numbers. The use of inadequate 
pseudorandom number generators (PRNGs) to generate cryptographic keys can result in little or 
no security. An attacker may find it much easier to reproduce the PRNG environment that 
produced the keys, searching the resulting small set of possibilities, rather than brute-force 
searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] 
offers important guidance in this area. 


Implementers should be aware that cryptographic algorithms become weaker with time. As new 
cryptanalysis techniques are developed and computing performance improves, the work factor 
to break a particular cryptographic algorithm will be reduced. Therefore, cryptographic 
algorithm implementations should be modular, allowing new algorithms to be readily inserted. 
That is, implementers should be prepared for the set of supported algorithms to change over 
time. 


The security properties provided by the mechanisms specified in this document can be validated 
using formal methods. A ProVerif proof in [H2019] shows that an attacker with a large-scale 
quantum computer that is capable of breaking the Diffie-Hellman key agreement algorithm 
cannot disrupt the delivery of the content-encryption key to the recipient and that the attacker 
cannot learn the content-encryption key from the protocol exchange. 


8. Privacy Considerations 


An observer can see which parties are using each PSK simply by watching the PSK key 
identifiers. However, the addition of these key identifiers does not really weaken the privacy 
situation. When key transport is used, the RecipientIdentifier is always present, and it clearly 
identifies each recipient to an observer. When key agreement is used, either the 
IssuerAndSerialNumber or the RecipientKeyldentifier is always present, and these clearly 
identify each recipient. 
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9. IANA Considerations 


One object identifier for the ASN.1 module in Section 6 was assigned in the "SMI Security for S/ 
MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry [IANA]: 


id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
pkcs-9(9) smime(16) mod(0) 69 } 


One new entry has been added in the "SMI Security for S/MIME Mail Security 
(1.2.840.113549.1.9.16)" registry IANA]: 


id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } 


A new registry titled "SMI Security for S/MIME Other Recipient Info Identifiers 
(1.2.840.113549.1.9.16.13)" has been created. 


Updates to the new registry are to be made according to the Specification Required policy as 
defined in [RFC8126]. The expert is expected to ensure that any new values identify additional 
RecipientInfo structures for use with the CMS. Object identifiers for other purposes should not be 
assigned in this arc. 


Two assignments were made in the new "SMI Security for S/MIME Other Recipient Info 
Identifiers (1.2.840.113549.1.9.16.13)" registry [IANA] with references to this document: 


id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
pkcs-9(9) smime(16) id-ori(13) 1 } 


id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 


iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
pkcs-9(9) smime(16) id-ori(13) 2 } 
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Appendix A. Key Transport with PSK Example 


This example shows the establishment of an AES-256 content-encryption key using: 


e a pre-shared key of 256 bits; 

e key transport using RSA PKCS#1 v1.5 with a 3072-bit key; 
e key derivation using HKDF with SHA-384; and 

e key wrap using AES-256-KEYWRAP. 
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In real-world use, the originator would encrypt the key-derivation key in their own RSA public 
key as well as the recipient's public key. This is omitted in an attempt to simplify the example. 


A.1. Originator Processing Example 


The pre-shared key known to Alice and Bob, in hexadecimal, is: 
c244cdd11a0d1f39d9b61282770244fb0Of6befb91ab7 f96cb05213365cf95b15 
The identifier assigned to the pre-shared key is: 
ptf-kmc:13614122112 
Alice obtains Bob's public key: 


arenas BEGENSPUBEVLCS KEN SoS 

MIIBoj ANBgkqhkiG9w0 BAQEFAAOCAY 8AMIIBi gKCAYEA30cW14cxncPI47fnEj BZ 
AyfC2LqapL3ET4j vV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH 
Keeza+itfuhsz3yi fgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq 
vS3jg/VO+OPnZbofoHOOevt8Q/ roahJe1PllyQ4udWB8zZezJ4mLLfbOA9YVaYXx 
2AHHZJevo3nmRnlgIXo6mEOOE/6qkhj DHKSMdL2WG6mO9TCDZc9qY3cAIDU6IrOv 
SH7qUL8/vN13y4U0Fkn8hM4kmZ6bIqbZt5NbjHtY4uQOVMW3RyESzhroOo02mrp39a 
uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3Y fFEGRKn8 fxubji716D8UecAxAzFy 
FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UUD4Mo050sOqOUpBIHA9FS 
whSZG7VNf+vgNWTLNYSYLI04KiMdu LnvU6ds+QPz+KKtAgMBAAE= 

So ENDSPUBLETEGS KEY = ———— 


Bob's RSA public key has the following key identifier: 
9eeb67c9b95a74d44d2 f16396680e801b5cba49c 
Alice randomly generates a content-encryption key: 
c8adc30f4a3e20ac420caa76a68F5787c02ab42afea20d19672 Fd963a5338e83 
Alice randomly generates a key-derivation key: 
df85af9e3cebf fde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde8leb 


Alice encrypts the key-derivation key in Bob's public key: 
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52693f12140c91dea2b44c0b7936f6be46de8a7bfabO072bcb6ec fd56b06a9fFE5 
1bd4669d336aef7b449e5cd9b151893b7c7a3b8e364394840b0a5434cbf10e1b 
5670ae fd074faf380665d204fb95153543346f36c2125dba6f4d23d2bc61434b 
5e36ff72b3eafe57c6cf7F74924c309F174b0b8753554b58ed33a8848d707a98 
cOc2bliddc fd09e31fe213ca0a48dd157bd7d842e85cc76f77710d58efeaa0525 
c651bcd1410fb47534ecabaf5ab7daabed809d4b97220caf6d4929c5fb684F7b 
b8692e6e70332ff9b3 f7c11d6cac51d4a35593173d48f80ca843b89789d625e7 
997ad7d674d25a2a7d165a5 f39b3cb6358e937bdb02ac8a524ac93113cedd9ad 
C68263025c0bb0997d716e58d4d7b69739bf591F3e71c7678dcOdf96F3df9e8a 
a5738f4f9ce21489 F300e040891b20b2ab6d9051b3c2e68efa2fa9799a706878 
d5f462018c021d6669ed649 f9acdf78476810198bfb8bd41ffedc585eafa957e 
eald3625e4bed376e7ae49718aee2 £575c401a26a29941d8da5b7ee9aca36471 


Alice produces a 256-bit key-encryption key with HKDF using SHA-384; the secret value is the 
key-derivation key; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with the 
following values: 


0 56: SEQUENCE { 
2 32) OCTET STRING 
C2 44 CD D1 1A OD 1F 39 D9 B6 12 82 77 O02 44 FB 
OES6B ERS BISA Bir EIR 6G BOS 213836 5CSE9e5B 215 
36 Als ENUMERATED 5 
39 11: SEQUENCE { 
41 Or OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45) 


: t 
52 Ji INTEGER 32 
593 Ik INTEGER 32 


J 
The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 


30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91lab7f96cb0521336 
5cf95b150a0105300b060960864801650304012d020120020120 


The HKDF output is 256 bits: 
f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9f00ca540a232 


Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption key with the key-encryption 
key: 


ea0947250 fa66cd525595e52a69aaade88efcf1lbOf108abe291060391bicdf59 
07f36b4067e45342 


Alice encrypts the content using AES-256-GCM with the content-encryption key. The 12-octet 
nonce used is: 


Housley Standards Track Page 19 


RFC 8696 Using PSK in the CMS December 2019 


cafebabefacedbaddecaf888 

The content plaintext is: 
48656c6c6f2c20776F726c6421 

The resulting ciphertext is: 
9af2d16f21547fcefed9b3ef2d 

The resulting 12-octet authentication tag is: 
a0e5925cc184e0172463c44c 


A.2. ContentInfo and AuthEnvelopedData 


Alice encodes the AuthEnvelopedData and the ContentInfo and sends the result to Bob. The 
resulting structure is: 
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105 
109 
alls} 
116 


138 


140 


TSN 


T53 


SEQUENCE { 
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OBJECT IDENTIFIER 
authEnvelopedData (1 2 840 113549 1 9 16 1 23) 


[o] f 
SEQUENCE { 
INTEGER 0 
SETEN 
EAA 


OBJECT IDENTIFIER 
keyTransPSK (1 2 840 113549 1 9 16 13 1) 


SEQUENCE { 
INTEGER 0 


OCTET STRING 'ptf-kmc:13614122112' 
SEQUENCE { 


OBJECT IDENTIFIER 


hkdf-with-sha384 (1 2 840 113549 1 9 16 3 29) 


J 


SEQUENCE { 


OBJECT IDENTIFIER 


aes256-wrap (2 16 840 1101341 


J 


SEQUENCE { 
SEQUENCE { 
INTEGER 2 


[0] 


SESEB SOI {ESM BIeSA: 
B5 CB A4 9C 


SEQUENCE { 


OBJECT IDENTIFIER 
rsaEncryption (1 


NUL 
t 


L 


OCTET STRING 


52 
46 
1B 
TAS 
56 
43 
5E 
If 
CO 
BD 
C6 
ED 
B8 
A3 
99 
58 
C6 
29 
A5 
AB 
D5 
76 
EA 
5C 


69 
DE 
D4 
7A 
70 
34 
36 
4B 
ee 
7D 
51 
80 
69 
55 
7A 
E9 
82 
BF 
73 
6D 
F4 
81 
1D 
40 


3F 
8A 
66 
3B 
AE 
6F 
FF 
OB 
B1 
84 
BC 
9D 
2E 
93 
D7 
37 
63 
59 
8F 
90 
62 
01 
36 
1A 


12 
7B 
9D 
8E 
FD 
36 
72 
87 
DD 
2E 
D1 
4B 
6E 
17 
D6 
BD 
02 
1F 
4F 
51 
01 
98 
25 
26 


14 
FA 
33 
36 
07 
C2 
B3 
53 
CF 
85 
41 
97 
70 
3D 
74 
BO 
5C 
3E 
9C 
B3 
8C 
BF 
E4 
A2 


OC 
BO 
6A 
43 
4F 
12 
EA 
55 
DO 
cc 
OF 
22 
33 
48 
D2 
2A 
OB 
rat 
E2 
C2 
02 
B8 
BE 
99 


74 


D4 


2 840 


91 
TOGA 
Ek 
94 
AF 
5D 
EE 
4B 
9E 
76 
B4 
OC 
PAF 
F8 
5A 
C8 
BO 
CT 
14 
E6 
1D 
BD 
D3 
41 


DE 
BC 
7B 
84 
38 
BA 
57 
58 
31 
F7 
75 
AF 
F9 
oc 
2A 
A5 
99 
67 
89 
8E 
66 
41 
76 
D8 
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A2 
B6 
44 
OB 
06 
6F 
C6 
ED 
FE 
wi 
34 
6D 
B3 
A8 
7D 
24 
7D 
8D 
F3 
FA 
69 
FF 
E7 
DA 


B4 
EC 
9E 
OA 
65 
4D 
CF 
33 
Pil 
10 
EC 
49 
F7 
43 
16 
AC 
al 
co 
00 
2F 
ED 
ED 
AE 
5B 


4C 
FD 
5C 
54 
D2 
23 
7F 
A8 
3C 
D5 
AB 
29 
Gil 
B8 
5A 
93 
6E 
DF 
EO 
AQ 
64 
C5 
49 
7E 


45) 


39 66 80 E8 


ET) 


OB 79 36 F6 
56 BO 6A 9F 
DOS BARS Aso 
34 CBIR OE 
04 FB 95 15 
D2 BC 61 43 
74 92 4C 30 
84 8D 70 7A 
AO A4 8D D1 
SETRESAASOS 
AF 5A B7 DA 
C5 FB 68 4F 
1D 6C AC 51 
979 90D6 T25 
SES Oe BSuCB' 
JE CREDIEDS 
58 D4 D7 B6 
96E DE 9E 
40 89 1B 20 
79 9A 70 68 
DES IAEC DME 
S5 TEATFAT95 
GUS CAR EE PZF 
E9 AC A3 64 


01 


BE 
65 
3B 
1B 
35 
4B 
SE 
98 
Sif, 
25 
AB 
7B 
D4 
E7 
63 
AD 
97 
8A 
B2 
78 
84 
TAs 
S 
Thal 
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541 


583 
585 
596 
598 


609 
611 


625 


640 


40: 


138 


T2 
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} 
} 
OCTET STRING 
EAROOF 47. 2 520 Re AOw6 Cm D5 2S Ro Oe IES 
So JERSCE IB ORMIOVSANBES29 “060839 
O07 F3 6B 40 67 E4 53 42 
i 
t 
J 
SEQUENCE { 
OBJECT IDENTIFIER data (1 2 840 113549 
SEQUENCE { 
OBJECT IDENTIFIER 
aes256-GCM (2 16 840 1 101 3 4 1 46) 
SEQUENCE { 
OCTET STRING 
CA FE BA BE FA CE DB AD DE CA F8 88 
} 
[0] 
SAS E2S DARG R254 ire Chere DIS BS BES?) 
} 
OCTEM<SMRINGSAQRESE 92" 5 CeGlyS4e EO Mliiee24. 
} 


A.3. Recipient Processing Example 


Bob's private key is: 
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MIIGS5AIBAAKCAYEA30cW14cxncPJ47 fnEj BZAy fC2 LqapL3ET4j vV6C7gGeVrRQx 
WPDwl+cFYBBR2ej3j3/0ecDmut+XuVi2+s5JHKeezatitfuhsz3yi fgeEpek8T+Su 
sHhn20/NBLhYKbh3k7iAcCgQ56dpDrDvDcLqqvS3j g/VO+0PnZbo foHOOevt8Q/ro 
ahJe1PlLIyQ4udWB8zZezJ4mLL fbOA9YVaYXx2AHHZJevo3nmRnlgIXo6mEOOE/6q 
khj DHKSMdlL2WG6mO9TCDZc9qY3cAIJDU6IrOvSH7qUL8/vN13y4U0Fkn8hM4kmZ6b 
JqbZt5Nbj HtY4uQOVMW3RyESzhr002mrp39aUuLNnH3EXdXaV1itk75H3qC7zJaeGW 
MJyQfOE3Y fEGRKn8 fxubj i 716D8UecAxAzFyFL6m1Ji0yV5acAiOpxN14qRYZdHn 
XOM9DqGIGpoeY 1UUD4Mo0050SOqOUpBIHA9 f SwhSZG7VNf+vgNWTLNYSYLIO4KiMd 
ulnvU6ds+QPz+KKtAgMBAAECggGATF fkSkUj j IC] LVDk4aScpSx6+Rakf2hrdS3x 
jwqhyUfAXgTTeUQQBS1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi /Z5yB1wOGJEV 
3k8N/ytul6pJFFn6p48VM01bUdT rkMIbXERe6g/rré6édBQeeItCaOK7N5SIIH30qgh 
9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOw1!j j MV8uUQUR8rHSO9KkSj 8AGs 
Lq9kcuPpvgJc20qMRcNePS2WVh8xPFktRLLRazgLP8STHAtj T6SlLI2ZUZkUq fDHGK 
q/BoXxBDu6L1VDwdnIS5HXtL54E LcXWsoOyKF8/7 LmhnRUIUWRZFmlS1lok8IC5Igx 
UdL9rjJVZFTRLyAwmcCEvRMlasbBrhyEyshSOuN5nHJ7i2WVJ+wSHi jeKLigeLlpMk 
HrdIYBq4Nz7/zXmiQphpAy+yQeanhP80406C8e7RwKkdpxe44su4Z8fEgA5yQxOu7 
8yRLEhGKydX5bhBLR5Cm1VM7rT2BAOHBAP/+e5gZLNf/ECtEBZjeiJOVshsz0o0Uq 
haUQPA+9Bx9pytsoKm5o0QhB7QDaxAvrn8/FUW2aAkaXxsaj 9F+/q30AYSQtExai9I 
fdkKKook30imN8/yNRsKmhfjGOj 8hd4+Gj XOqoMSBCEVdT+bAjj ry8wgQrqReuZnu 
oXU85dmb3j vvOuIczIKvTleyj XE5afjQIILmZFXsBm09BG87Ia5EFUKLy96BOMIh 
/QWEzuYYXDqOF fzQtkAef XNFW21Kz4Hw2QKBwQDeiGh4 LxCGTj ECvG7 fauMGLu+q 
DSdYyMHi f6t6mx57eS16Ej vOr lXKItYhlyzwskwOrf/CSB2j8ig1GkMLTOgrGIJ1 
0322050FOr500mZPueeR4pOyAPO0fgQ8DDIL3IBpY68/8MhYbsizVrR+Ar4jMOf96 
W2bF5Xj3h+fQTDMkx6VrCCQ6mi RMBUZH+ZPs5n/LYOZAYrqikOanaiHy4mjRvlsy 
mj Z6z5CG8sISqcLQ/k3Q1i5pOY/voOrdBj gwAW/UCgcEAqGVYGj KdXCzuDvf9EpV4 
mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZtOvMbu28Px7sSpkqUuBKbzJ4pcy8uC31 
SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+ XMOh6j VRHXHhOnOXdV fF gnmi gPGz3j4VI 
B8o0ph/jD802YCk4YCTDOXPE7i8RjusxzrotwhvRR+kGOgsGGcKSVNCPj1fNISEte4 
gJId701mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAOHBAInFHIunl22W/ irr 
ppmPniIzj 130YVcYOA5v LqLKyGaAsnfYqP1WUNg fVhq2j RsrHx9cnHQI9Hu442PvI1 
x+c5H30YFI47pE3eRRRmAU74ghY 5WegD+1hw8 fqyUW7E7 LSLbDSbGEUVXtrkU5G64T 
URQLLEyMF80PATdiV/KD4PWYkgaqRm3tVEUCVACDTQkqNs0O0713YPQcm270w6gxFfQ 
SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBi LR/ yCxqKOONqLFdOQKBwFbJk5eHPj Iz 
AYueKMQESPGYCrwiqxgZGCxaqeVArHvKSEDx5whI6JWoFYVkFA8FOMyhukoEb/2x 
2qB5T88Dg3Ebqj TiLg3qxrwJ20xtUo8pBP2I2wbl2NOwzcbr LYhzEZ8bJyxZu5i1 
SYILC8PI4Qzw6j S4Qpm4y1WHz8e/ELW6Vy fm1j ZYA7 f9WMntdfeQVqCVZNTvKn6f 
hg6GSpJTzp4LV30ugi 9nQUWXZF2wInsXkLYpsiMbL6Fz34RwohJItYA== 

SSeS END RSA PRIVATE KEY----- 


ecrypts the key-derivation key with his RSA private key: 


dfs85af9e3cebf fde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde8l1leb 


December 2019 


Bob produces a 256-bit key-encryption key with HKDF using SHA-384; the secret value is the key- 
derivation key; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with the 


same 


Housley 


values as shown in Appendix A.1. The HKDF output is 256 bits: 


f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9 F00ca540a232 
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Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the key-encryption key; the 
content-encryption key is: 


c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672 Fd963a5338e83 


Bob decrypts the content using AES-256-GCM with the content-encryption key and checks the 
received authentication tag. The 12-octet nonce used is: 


cafebabefacedbaddecaf888 
The 12-octet authentication tag is: 

a0e5925cc184e0172463c44c 
The received ciphertext content is: 

9af2d16f21547 fcefed9b3ef2d 
The resulting plaintext content is: 


48656c6c6f2c20776F726c6421 


Appendix B. Key Agreement with PSK Example 


This example shows the establishment of an AES-256 content-encryption key using: 


e a pre-shared key of 256 bits; 

e key agreement using ECDH on curve P-384 and X9.63 KDF with SHA-384; 
e key derivation using HKDF with SHA-384; and 

e key wrap using AES-256-KEYWRAP. 


In real-world use, the originator would treat themselves as an additional recipient by performing 
key agreement with their own static public key and the ephemeral private key generated for this 
message. This is omitted in an attempt to simplify the example. 


B.1. Originator Processing Example 


The pre-shared key known to Alice and Bob, in hexadecimal, is: 


4aa53cbf500850dd583a5d9821605c6fa228 fb5917 f87c1c078660214e2d83e4 
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The identifier assigned to the pre-shared key is: 
ptf-kmc:216840110121 
Alice randomly generates a content-encryption key: 
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 
Alice obtains Bob's static ECDH public key: 


Soo BEGENEIRUBELEsKEV SS = — 

MHYwEAYHKoZIzj OCAQY FK4EEACIDY gAEScGPBO9nmUwGr gbGEoFY9HR/bCoOWyeY 
/dePQVrwZmwN2yMJmO2d1LkWCvLTz8U7atinxyIRe9CV54yaulKWU/wbkhPDnzuSM 
YkcpxMGo32z3JetE LoW5aFOjal3vv/W5 

----- END PUBLIC KEY----- 


It has a key identifier of: 
e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 


Alice generates an ephemeral ECDH key pair on the same curve: 


MIGkAgEBBDCMiWLG447k+L8cYVvJIrQdLcFA+PwlgRF+WtlAb25qUh80B70ePWj xp 
/b8P6IOuI6GgBwYFK4EEACKhZAN7AAQ5GOEmIK/2ks8sXY1kzbuG3Uu3 ttWwQRXA 
LFDIJICjvY fr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3Dt0g760LYENpPb 
GE5LIdjPx9sBSZQdABwlsSUOZb7P/778= 

Sass ENDVECSRRIVATESKEN S oo 


Alice computes a shared secret called "Z" using Bob's static ECDH public key and her ephemeral 
ECDH private key; Z is: 


3f015ed0ff4b99523a95157bbe7 7e9ccOee52fcffeb7e4leac79d1c11b6cc556 
19cf8807e6d800c2de40240 fe0e26adc 


Alice computes the pairwise key-encryption key, called "KEK1", from Z using the X9.63 KDF with 
the ECC-CMS-SharedInfo structure with the following values: 
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0 21 SEQUENCES 
2 alial SEQUENCE { 


4 9: OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45) 
; } 
15 6: at 
17 4: OCTET STRING 00 00 00 20 
: } 
} 


The DER encoding of ECC-CMS-SharedInfo produces 23 octets: 
3015300b060960864801650304012da206040400000020 

The X9.63 KDF output is the 256-bit KEK1: 
27dc25ddb0b425 f7a968ceada80a8 F73c6ccaabli5baafcce4a22a45d6b8 f3da 


Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret value is KEK1; and the 
‘info' is the DER-encoded CMSORIforPSKOtherInfo structure with the following values: 


0 56: SEQUENCE { 
2 32%; OCTET STRING 
4A AS: 3C BE 50. 08-50) (DD) 58' SA 5D 98"21, 60 5C 6F 
A222 35 FB SOAMES Cel ClO eC OeOOe Ze 4 E27 DESEA 
36 ake ENUMERATED 10 
29 IEE SEQUENCE { 
41 OF OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45) 


: t 
52 deo INTEGER 32: 
55 ies?) INTEGER S32. 
t 


The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 


303804204aa53cbf500850dd583a5d9821605c6 fa228 fb5917 f87c1c07866021 
4e2d83e40a010a300b060960864801650304012d020120020120 


The HKDF output is the 256-bit KEK2: 
7de693ee30ae22b5 f8Ff6cd026c2164103 f£4e1430 f1ab135dc1fb98954f9830bb 


Alice uses AES-KEY-WRAP to encrypt the content-encryption key with the KEK2; the wrapped key 
is: 
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229fe0b45e40003e7d8244ec1b7e7 f fb2c8dcal6c36f5737222553a71263a92b 
de08866a602d63 f4 


Alice encrypts the content using AES-256-GCM with the content-encryption key. The 12-octet 
nonce used is: 


dbaddecaf888cafebabeface 

The plaintext is: 
48656c6c6f2c20776F726c6421 

The resulting ciphertext is: 
fc6d6f823e3ed2d209d0cé6f fcf 

The resulting 12-octet authentication tag is: 


550260c42e5b29719426c1f fF 


B.2. ContentInfo and AuthEnvelopedData 


Alice encodes the AuthEnvelopedData and the ContentInfo and sends the result to Bob. The 
resulting structure is: 
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100 
IOB 


162 
164 


177 
179 


190 
192. 
194 
196 


218 


260 
262 
DEES) 


60: 
Silas 


TSK 
dalk? 


40: 


55% 


DE 
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SEQUENCE { 
OBJECT IDENTIFIER 
authEnvelopedData (1 2 840 113549 19 16 1 23) 
[o] { 
SEQUENCE { 
INTEGER 0 
SETEL 
KI 
OBJECT IDENTIFIER 
keyAgreePSK (1 2 840 113549 19 16 13 2) 
SEQUENCE { 
INTEGER 0 
OCTET STRING 'ptf-kmc:216840110121' 
TOTI 
EE 
SEQUENCE { 
OBJECT IDENTIFIER 
ecdhX963KDF-SHA256 (1 3 132 1 11 1) 
OBJECT IDENTIFIER 
aes256-wrap (2 16 840 1 101 3 4 1 45) 
} 
BIT STRING, encapsulates { 
OCTET STRING 


1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD 
4B B7 Bo D5 BO 41 15 CO 2C 50 C9 20 28 EF 61 FA 
FESS: 3A 4E 41°59 1 86 6F 3G 14.08 7D 30-49 30 


EO D2 9C B6 89 OA 36 OA 6C 
t 
} 
} 
SEQUENCE { 
OBJECT IDENTIFIER 


hkdf-with-sha384 (1 2 840 113549 1 9 16 3 29) 


} 
SEQUENCE { 
OBJECT IDENTIFIER 
aes256-wrap (2 16 840 1 101 3 4 1 45) 
} 
SEQUENCE { 
SEQUENCE { 
KOs 
OCTET STRING 


E872178B298 FB8 Bie D8 oBaoE. SEs BDBC8PAESBS sC4y EE 


DESO 5S3:C5229 


i 
OCTET STRING 


22 9F EO B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB 
2CESDUCAMIGNCSS OR 251. Si 220255 OSA 2 AOS 3 AIE 2B 


DE 08 86 6A 60 2D 63 F4 
} 
} 
} 
} 
} 
SEQUENCE { 
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 
SEQUENCE { 
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25 OF OBJECT IDENTIFIER 
: aes256-GCM (2 16 840 1 101 3 4 1 46) 
286 14: SEQUENCE { 
288 12: OCTET STRING 
4 DB AD DE CA F8 88 CA FE BA BE FA CE 
} 
: ii 
302 abst LO] 
; EG ODAGE 823E 3E D2 D209 DO C6Sakr CE 
: } 
2a 12: OGTET STRING:55702160 CAPET 5B. 29) 7 94°26) Cl EF 
: } 
} 
} 


B.3. Recipient Processing Example 


Bob obtains Alice's ephemeral ECDH public key from the message: 


MHYwEAYHKoZIzj OCAQYFK4EEACIDY gAEORtBJ7ZP9pLPLF2NZM27ht1Lt7bVSEEV 
wCxQySAo72H6/sk6TkFZHIZVPBQIfTBIMODSnLaJCj YKbKL8q@9w7T00+qCGBDaT 
2xhOZSXYz8fbAbGUHQACIbFNGW+z/+4v 

----- END PUBLIC KEY----- 


Bob's static ECDH private key is: 


MIGkAgEBBDAnJ4hB+tTUN9X03/WORsrYy+qcpt LRSYkhaDIsQYPX fTUOugj JEmRk 
NTP34y11Rj egBwYFK4EEACKhZAN7AARIJwY8E72eZTAauBsYSgVj OdH9SKjRDI539 
149BWvBmbA3bIwmY7Z3WRYK8tPPxT tq2KfHIhF70IXnj Iq7UpZT / BUSE8O0fFO51xi 
RynEwaj fbPclL60SWhbLOUENrXet+/9bk= 

Saale END EG PRIVATE KEY -= 


Bob computes a shared secret called "Z" using Alice's ephemeral ECDH public key and his static 
ECDH private key; Z is: 


3f015ed0ff4b99523a95157bbe7 7e9ccOee52fcffeb7e4leac79d1c11b6cc556 
19cf8807e6d800c2de40240fe0e26adc 


Bob computes the pairwise key-encryption key, KEK1, from Z using the X9.63 KDF with the ECC- 
CMS-SharedInfo structure with the values shown in Appendix B.1. The X9.63 KDF output is the 
256-bit KEK1: 


27dc25ddb0b425 f7a968ceada80a8f73c6ccaabli5baafcce4a22a45d6b8 f3da 
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Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret value is KEK1; and the 'info' 
is the DER-encoded CMSORIforPSKOtherInfo structure with the values shown in Appendix B.1. 
The HKDF output is the 256-bit KEK2: 


7de693ee30ae22b5f8F6cd026c2164103 £4e1430flab135dc1fb98954f9830bb 


Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the KEK2; the content- 
encryption key is: 


937b1219a64d57ad81c05cc86075e86017848c824d4e85800C731c5b7b091033 


Bob decrypts the content using AES-256-GCM with the content-encryption key and checks the 
received authentication tag. The 12-octet nonce used is: 


dbaddecaf888cafebabeface 
The 12-octet authentication tag is: 

550260c42e5b29719426c1f fF 
The received ciphertext content is: 

fc6d6f823e3ed2d209d0cé6f fcf 
The resulting plaintext content is: 


48656c6c6f2c20776F726c6421 
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